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PREFACE 

This  Memorandum  describes  an  on-lir.  ,  graphical, 
man/machine  interactive  computer  system  that  employs  the 
RAND  Tablet.  The  system  provides  aids  for  solving  a 
particular  problem  of  interactive  design,  and,  it  is  hoped, 
will  result  in  significant  new  solutions.  The  firing  squad 
synchronization  problem  was  chosen  because  it  affords  an 
opportunity  for  evaluating  the  problem-solving  power  of 
both  the  particular  aids  and  such  systems  as  a  whole. 

R.  W.  Shirey  participated  in  the  1967  RAND  Summer 
Graduate  Program  and  is  now  a  RAND  Consultant.  He  is  pre¬ 
sently  a  doctoral  candidate  in  Computer  Sciences  at  the 
University  of  Wisconsin. 


SUMMARY 


This  Memorandum  describes  a  computer  system  designed 
both  to  investigate  man/machine  graphical  communications 
and  to  find  improved  solutions  for  the  firing  squad  syn¬ 
chronization  problem.  The  system  provides  aids  that  allow 
the  user  to  approach  this  problem  by  methods  he  might  other¬ 
wise  not  attempt  because  of  the  tedious  hand  calculations 
required.  Furthermore,  the  graphical  nature  of  the  system 
and  the  type  of  aids  provided  combine  to  influence  signifi¬ 
cantly  the  attitude  of  the  experimenter  toward  various  solu¬ 
tion  approaches. 

First,  the  authors  state  the  problem  and  note  some  of 
its  inherent  difficulties.  Next,  they  discuss  the  necessary 
tasks  for  solving  the  problem,  and  then  go  on  to  show  how 
and  why  some  of  these  tasks  should  be  automated.  Then, 
finally,  the  authors  discuss  general  principles  learned 
while  building  the  system,  and  make  recommendations  con¬ 
cerning  the  cost  and  advisability  of  constructing  similar 
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I .  INTRODUCTION 


The  purpose  of  this  study  is  to  investigate  man/ma¬ 
chine  interaction  in  the  context  of  solving  a  conceptually 
difficult,  formal  problem.  We  want  a  problem  that  requires 
no  specialized  knowledge,  so  that  a  fair  comparison  can  be 
made  between  computer-aided  and  unaided  attempts  at  solu¬ 
tion.  We  also  want  a  problem  that  is  graphic.  The  firing 
squad  synchronization  problem  satisfies  these  criteria  ex¬ 
tremely  well.  It  has  the  added  advantage  that  no  optimal 
solution  has  yet  been  produced. 

The  system  designed  for  these  purposes  is  essentially 
a  collection  of  problem-solving  aids  that  can  be  divided 
into  three  main  groups:  the  first  includes  bookkeeping 
aids,  useful  displays  of  information,  ability  to  get  hard 
copy,  and  other  basic  services;  the  second,  means  for  test¬ 
ing  and  simulating  solutions;  the  third,  specialized,  high- 
level  heuristic  aids  for  creating  solutions.  All  three 
groups  attempt  to  extend  the  user's  power  in  exploring  the 
universe  of  the  problem,  enabling  and  encouraging  him  to 
approach  the  problem  in  ways  that  might  otherwise  be  pro¬ 
hibited  by  immense  amounts  of  necessary  hand  calculations 
or  the  human  tendency  toward  error. 

We  hope  that  this  system  will  result  in  interesting 
new  solutions  to  the  firing  squad  problem,  and  will  provide 
new  information  on  the  reactions  of  humans  in  such  man/ 
machine  interactive  environments. 


We  begin  by  stating  the  problem  and  noting  some  of 
its  inherent  difficulties.  Next,  we  discuss  the  necessary 
tasks  for  solving  the  problem,  and  then  go  on  to  show  how 
and  why  some  of  these  tasks  should  be  automated.  Then, 
finally,  we  make  general  recommendations  concerning  the 
design  of  similar  computer  systems,  based  on  the  experience 
gained  while  constructing  this  one. 
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II.  PROBLEM  .STATEMENT 


This  Memorandum  concerns  a  problem  publically  first 

presented  in  1964  by  E.  F.  Moore  [1]: 

The  problem  known  as  the  firing  squad  synchronization 
problem  was  devised  about  the  year  1957  by  John  Myhill, 
but  so  far  as  I  know  the  statement  of  the  problem  has 
not  yet  appeared  in  print.  It  has  been  widely  circu¬ 
lated  by  word  of  mouth,  and  has  attracted  sufficient 
interest  that  it  ought  to  be  available  in  print.  The 
problem  first  arose  in  connection  with  causing  all 
parts  of  a  self -reproducing  machine  to  be  turned  on 
simultaneously.  The  problem  was  first  solved  by  John 
McCarthy  and  Marvin  Minsky,  and  now  that  it  is  known 
to  have  a  solution,  even  persons  with  no  background 
in  logical  design  or  computer  programming  can  usually 
find  a  solution  in  a  time  of  two  to  four  hours.  The 
problem  has  an  unusual  elegance  in  that  it  is  directly 
analogous  to  problems  of  logical  design,  systems  de¬ 
sign,  or  programming,  but  it  does  not  depend  on  the 
properties  of  any  particular  set  of  logical  elements 
or  the  instructions  of  any  particular  computer.  I 
would  urge  those  who  know  a  solution  to  this  problem 
to  avoid  divulging  it  to  those  who  are  figuring  it  out 
for  themselves,  since  this  will  spoil  the  fun  of  this 
intriguing  problem. 

Consider  a  finite  (but  arbitrarily  long)  one  dimen¬ 
sional  array  of  finite-state  machines,  all  of  which 
are  alike  except  the  ones  at  each  end.  The  machines 
are  called  soldiers,  and  one  of  the  end  machines  is 
called  a  general.  The  machines  are  synchronous,  and 
the  state  of  each  machine  at  time  t  +  1  depends  on  the 
states  of  itself  and  of  its  two  neighbors  at  time  t. 

The  problem  is  to  specify  the  states  and  transitions 
of  the  soldiers  in  such  a  way  that  the  general  can 
cause  them  to  go  into  one  particular  terminal  state 
(i.e.,  they  fire  their  guns)  all  at  exactly  the  same 
time.  At  the  leginning  (i.e.,  t  =  0)  all  the  soldiers 
are  assumed  to  be  in  a  single  state,  the  quiescent  state. 
When  the  general  undergoes  the  transition  into  the  state 
labeled  "Fire  when  ready,"  he  dees  not  take  any  initia¬ 
tive  afterwards,  and  the  rest  is  up  to  the  soldiers. 

The  signal  can  propagate  down  the  line  no  faster  than 
one  soldier  per  unit  of  time,  and  their  problem  is  how 
to  get  all  coordinated  and  in  rhythm.  The  tricky  part 
of  the  problem  is  that  the  same  kind  of  soldier  with 
a  fixed  number  K  of  states  is  required  to  be  able  to 
do  this,  regardless  of  the  length  N  of  the  firing  squad. 
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In  particular,  the  soldier  with  K  states  should  work 
correctly,  even  when  N  is  much  larger  than  K.  Roughly 
speaking,  none  of  the  soldiers  is  permitted  to  count 
as  high  as  N. 

Two  of  the  soldiers,  the  general  and  the  soldier 
farthest  from  the  general,  are  allowed  to  be  slightly 
different  from  the  other  soldiers  in  being  able  to  act 
without  having  soldiers  on  both  sides  of  them,  but 
their  structure  must  also  be  independent  of  N. 

A  convenient  way  of  indicating  a  solution  of  this 
problem  is  to  use  a  piece  of  graph  paper,  with  the 
horizontal  coordinate  representing  the  spatial  position 
and  the  vertical  coordinate  representing  time.  Within 
the  (i,  j)  square  of  the  graph  paper  a  symbol  may  be 
written,  indicating  the  state  of  the  ith  soldier  at 
time  j.  Visual  examination  of  the  pattern  of  propaga¬ 
tion  of  these  symbols  can  indicate  what  kinds  of 
signaling  must  take  place  between  the  soldiers. 

Any  solution  to  the  firing  squad  synchronization  prob¬ 
lem  can  easily  be  shown  to  require  that  the  time  from 
the  general's  order  until  the  guns  go  off  must  be  at 
least  2N-2,  where  N  is  the  number  of  soldiers.  Most 
persons  solve  this  problem  in  a  way  which  requires 
between  3N  and  8N  units  of  time,  although  occasionally 
other  solutions  are  found.  Some  such  other  solutions 
require  5/2N  and  of  the  order  of  N-squared  units  of 
time,  for  instance.  Until  recently,  it  was  not  known 
what  the  smallest  possible  time  for  a  solution  was. 
However,  this  was  solved  at  M.I.T.  by  Professor  E.  Goto 
of  the  University  of  Tokyo.  The  solution  obtained  by 
Goto  used  a  very  ingenious  construction,  with  each 
soldier  having  many  thousands  of  states,  and  the  solu¬ 
tion  required  exactly  2N-2  units  of  time.  In  view  of 
the  difficulty  of  obtaining  this  solution,  a  much  more 
interesting  problem  for  beginners  is  to  try  to  obtain 
some  solution  between  3N  and  8N  units  of  time,  which 
as  remarked  above,  is  relatively  easy  to  do.* 

Goto ' s  solutic  ]  apparently  has  not  been  published. 
However,  Abraham  Waksman  [3]  has  found  a  16-state  minimal¬ 
time  solution  using  essentially  the  same  ideas  presented  in 


Ref.  1,  pp.  213-219. 
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Sec.  II  below, 
ideas  in  discuss 
iterative  arrays 
tion  to  date  is 
solution . 


P.  c.  Fischer  [4]  has  also  used  these 
ing  other  properties  of  one-dimensional 
of  finite-state  machines.  The  best  solu 
r.  M.  Balzer ' s  [5]  8-state  minimal-time 
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III.  COMMON  APPROACHES  AND  BASIC  CONSIDERATIONS 


The  firing  squad  synchronization  problem  can  be  solved 
by  successively  subdividing  the  line  into  any  number  of 
equal  parts,  then  subdividing  each  of  these  parts  similarly, 
and  so  on,  until  all  the  members  of  the  line  become  division 
points,  at  which  time  they  all  fire.  Most  existing  solu¬ 
tions  use  this  technique,  and  it  can  provide  solutions  of 
minimal  time,  2N-2.  Balzer's  solution  [5]  divides  the  line 
into  halves,  quarters,  eighths,  etc. 

Finding  a  solution  entails  construction  of  a  finite- 
state  machine  by  defining  for  the  machine  a  transition 
function  that  yields  appropriate  behavior  when  placed  in 
the  iterative  array.  Although  automata  are  usually  defined 
by  state  tables,  here  it  is  easier  to  interpret  a  function 
as  a  set  of  rules  called  productions.  These  rules  take  the 
form 


LMR  -*•  S. 

This  rule  states  that  if,  at  time  t,  a  machine  is  in  state 
M,  and  the  machine  on  its  left  is  in  state  L,  and  the  ma¬ 
chine  on  its  right  is  in  state  R,  then  the  machine's  state 
at  time  t+1  is  S.  We  call  S  the  "resultant"  of  the  produc¬ 
tion. 

In  particular,  we  are  concerned  only  with  minimal¬ 
time  solutions.  To  treat  the  problems  resulting  from  the 
soldiers  at  each  end  of  the  line,  we  use  an  additional  state 
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as  an  end  marker,  and,  at  each  end  of  the  line,  a  virtual 
additional  machine  which  forever  remains  in  the  marker 
state.  Since  no  other  machine  is  ever  in  the  marker  state, 
a  single  set  of  productions  can  be  defined  for  all  machines 
in  the  array. 

Exhaustive  search  for  the  function  is  out  of  the  ques¬ 
tion,  even  with  the  help  of  a  computer,  because  the  number 
of  possible  state  tables  is  far  too  large.  For  example,  if 

we  seek  a  solution  with  ten  states  (plus  the  end  marker) , 

3  2 

there  will  be  9  +2.9  -2=  889  productions.  (The  problem 

statement  excludes  certain  productions  and  fixes  the  resultant 

of  two  others.)  Each  of  the  889  productions  can  assume  ten 

88  9 

values,  for  a  total  of  10  functions. 

SOLUTION  BY  HAND 

While  building  a  function,  say  with  ten  states,  the 
experimenter  faces  a  number  of  separate  tasks — some  routine, 
some  challenging,  many  time-consuming  and  tedious.  He 
obviously  must  maintain  a  large  production  table.  Given 
some  table,  perhaps  only  partially  completed,  he  will  need 
to  test  it  on  firing  squads  of  different  lengths.  This 
simply  involves  retrieving  values  from  the  table  and  copying 
them  onto  graph  paper.  Both  tasks  are  routine;  nevertheless, 
performing  them  will  consume  much  of  the  experimenter's  time. 

After  several  attempts,  he  may  discover  that  some  pro¬ 
ductions  are  more  important  than  others,  that  they  are  keys 
to  the  solution,  and  he  might  wish  to  mark  these  in  order  to 
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remind  himself  that  their  values  should  not  be  altered  with¬ 
out  special  consideration. 

The  challenging  tasks  are  the  creative  ones,  and  the 
foremost  of  these  is  the  creation  of  ingenious  approaches 
to  the  problem.  These  schemes  usually  appear  as  a  two- 
dimensional  plan  for  propagation  of  signals  along  the  squad 
through  time.  One  method  for  simultaneously  implementing 
and  testing  an  approach  is  to  draw  on  the  graph  paper  a 
skeleton  diagram  of  the  intended  function  behavior,  and 
then  force  the  productions  to  conform  to  this  plan.  This 
method  of  defining  productions  eliminates  many  false  steps. 

Special  cases  arise  when  the  squad  is  quite  short,  say 
less  than  fifteen  men.  After  a  large  portion  of  the  produc¬ 
tion  set  is  defined,  especially  key  productions,  and  the 
function  has  been  tested  on  longer  squads,  exhaustive  search 
may  become  feasible  for  filling  in  the  special  productions 
required  for  these  cases. 

If  an  error  occurs  in  a  simulation,  such  as  a  soldier 
firing  too  early  or  too  late,  or  if  contradictions  arise 
while  attempting  to  fit  productions  to  a  behavior  skeleton, 
some  production  must  be  changed.  The  experimenter  then 
becomes  interested  in  why  he  originally  made  this  definition. 
Therefore  he  finds  it  useful  to  keep  a  history  of  production 
usage,  particularly  a  table  of  first  usages  in  the  simula¬ 
tion  he  is  currently  considering. 


In  all  these  tasks  there  is  a  high  probability  of 
human  error  due  to  the  large  size  of  the  tables,  the  large 
number  of  separate  acts  to  be  performed,  and,  of  course, 
the  repetitious  nature  of  most  of  the  work. 

SOLVING  WITH  COMPUTER  AIDS 

The  mechanically  repetitious  nature  of  some  tasks 
naturally  leads  to  thoughts  of  automating  them--providing 
computer  aids  for  the  experimenter.  The  obvious  candidates 
for  automation  are  those  tasks  which  primarily  consist  of 
information  storage  and  retrieval,  such  as  table  maintenance 
and  simulation.  Exhaustive  search,  where  feasible,  is 
handled  best  by  a  computer.  Having  provided  these  basic 
services,  other  more  sophisticated  tools  become  possible 
as  well.  Finally,  the  graphic  nature  of  both  the  problem 
and  the  methods  previously  described  influences  the  choice 
of  computing  hardware;  graphic  input  and  output  quickly  come 
to  mind. 

The  use  of  interactive  graphic  equipment  is  implied 
because  the  reactions  of  humans  to  a  computing  system  are 
highly  important.  A  rapid  interaction  between  man  and 
machine  tends  to  stimulate  the  intuition  and  perceptivity 
of  the  experimenter;  immediate  response  from  the  machine 
maintains  a  high  level  of  human  cerebral  activity.  Just  as 
not  having  computer  aids  at  all,  using  them  off-line  would 
slow  the  response  from  a  second  or  less  to  hours.  Progress 
might  become  so  slow  that  the  user  would  lose  interest  in 
the  problem. 
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SUMMARY  REMARKS  ON  THE  PROBLEM 

Let  us  summarize  the  above  discussion--of  the  problem 
and  the  comparison  between  attempts  at  solution  with  and 
without  computer  aids — in  order  to  draw  some  conclusions 
about  the  value  of  this  study. 

The  problem  is  interesting  enough  to  have  attracted 
wide  attention,  but  difficult  enough  that  no  optimal  solu¬ 
tion  has  been  demonstrated.  It  requires  no  special  back¬ 
ground,  and  is  simple  enough  that  at  least  an  inefficient 
solution  can  be  found  by  hand  in  a  few  hours.  Conversely, 
it  is  rich  enough  to  suggest  a  computer  implementation  of 
a  number  of  tools  and  techniques  to  aid  the  investigator. 
Also,  it  is  naturally  oriented  toward  the  use  of  inter¬ 
active  graphic  hardware. 

Furthermore,  since  exhaustive  search  for  a  solution 
is  not  practical,  the  computer  aids  are  only  tools,  and 
the  user  still  must  provide  the  creative  insights  and 
approaches  necessary  to  finding  a  solution.  Thus,  the 
firing  squad  synchronization  problem  is  a  particularly 
suitable  vehicle  for  evaluating  the  effectiveness  of  inter¬ 
active,  graphical  problem-solving  aids  by  comparing  their 
effects  with  the  results  of  unaided  efforts. 
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IV.  THE  SYSTEM  IN  GENERAL 

The  Firing  Squad  Synchronization,  Simulation  and 
Solution  System  (FS5)  is  a  highly  interactive,  graphical 
computer  system.  It  furnishes  three  basic  groups  of  tools: 
the  first  includes  bookkeeping  for  tables;  the  second  deals 
with  simulation  and  testing;  a  third  contains  the  more 
sophisticated  tools,  including  the  ability  to  draw  and 
implement  a  skeleton  plan,  request  exhaustive  searches, 
and  other  functions  not  obviously  needed,  but  included  on 
the  basis  of  experience  with  the  problem.  Associated  with 
these  three  main  categories  is  a  corona  of  minor  devices 
(e.g.,  for  obtaining  hard  copy  of  displays). 

HARDWARE,  SOFTWARE  AND  INTERACTION 

The  FS5  program  is  written  in  IBM  System/360  PL/I 
language  and  runs  on  an  IBM  System/360  Model  40.  A  user 
communicates  with  the  computer  via  a  RAND  Tablet  [6]  in 
conjunction  with  an  IBM  2250  cathode  ray  tube  (CRT)  display. 
The  tablet  hardware  consists  of  a  horizontal  10.24-inch- 
square  writing  surface  and  a  pen-like  writing  instrument, 
together  having  a  resolution  of  100  lines  per  inch  along 
both  Cartesian  coordinates. 

As  the  user  moves  the  stylus  near  the  tablet  surface, 
a  (hardware  generated)  dot  on  the  CRT  follows  the  stylus 
motion;  this  direct  feedback  helps  the  user  to  position 
the  stylus  for  pointing  or  drawing.  When  he  presses  the 
stylus  against  the  tablet  writing  surface,  a  switch  in  the 
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stylus  closes,  notifying  the  computer  that  the  user  is 
beginning  a  stroke.  As  he  moves  the  stylus  across  the 
tablet,  the  stylus  track  is  displayed  (via  software)  on 
the  CRT;  the  stylus  thus  seems  to  have  "ink."  When  the 
stylus  is  lifted,  its  switch  is  opened  notifying  the  com¬ 
puter  of  a  stroke  completion,  and  "inking"  ceases.  A  user 
may  "point"  at  an  area  on  the  CRT  by  closing  and  opening 
the  stylus  switch  on  the  corresponding  area  of  the  tablet 
surface . 

The  FS5  program  uses  a  set  of  graphics  subroutines 
written  at  RAND  and  called  the  Integrated  Graphics  System 
( IGS) .  Both  character  and  geometric  pattern  recognition 
are  included  in  IGS  [7] .  A  character  written  by  the  user 
is  replaced  on  the  display  by  the  corresponding  machine¬ 
generated  character. 

The  FS5  system  presents  the  user  with  a  picture  of  a 
control  panel  (Fig.  1) .  The  controls  are  used  as  if  they 
were  physical  buttons;  they  are  "pushed"  by  touching  them 
with  the  stylus.  Problem  information  is  displayed  in  three 
main  areas.  On  the  left,  FS5  shows  the  simulations  of  firing 
squads  from  length  one  to  length  25.  On  the  right,  there 
is  a  scroll  display  of  production-usage  history.  At  the 
top  center,  FS5  offers  a  variety  of  messages  concerning 
its  own  use  and  status.  The  use  and  function  of  the  con¬ 
trols  are  described  in  the  following  sections. 
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- tV - 

0  MESSAGE  CENTER 


LENGTH  25  |  #  OF  STATES 

]  20 

STATES 

IMAGES 

ABCDEFGHIJKLMNOPQRST 

ABCDEFGHI  JKLMNOPQRST 

FIRST  OCCURENCE  RESPONSES 

STOP 

AUTO  J  NORMAL 

BRIGHT 

DEFINE  CONSTRAINT 

REMOVE  LAST 

CLEAR  SQUAD 

CLEAR  FUNCTION 

CLEAR  CONSTRAINTS 

FREEZE  VALUE 

START  SQUAD 

DELETE  VALUE 

STOP  SQUAD 

PRINT  SQUAD 

PRINT  FUNCTION 

EXIT  PROGRAM 


DEFINE  FROZEN 


FREE 


ABC 


CHECK  SOLUTION 


500 


500 


DOl 


SNAP  VIEW  ON 


SNAP  VIEW  OFF 


IMAGE  SOLUTION  ON 


IMAGE_  SOLUTION^  OFJFj 


[  CONFIRM  ACTION 

v<» - 


SCROLL 
UP  DOWN 


Fig.  1 — The  Firing  Squad  Simulator  Scope  Face 


-14- 


NUMBBR  OF  STATES  AND  EXTERNAL  STATE  NAMES 

Suppose  an  experimenter  wishes  to  search  for  a  10-state 
solution.  He  begins  by  writing  "10"  in  the  space  provided: 


#  of  states 


10 


For  mnemonic  purposes,  he  will  find  it  convenient  to  have 
the  states  represented  by  alphabetic  characters  or  other 
symbols.  For  example,  he  might  use  acronyms:  "Q"  for  the 
quiescent  state;  "G"  for  the  general;  "F"  for  the  firing 
state.  Thus,  after  the  number  of  states  is  selected,  FS5 
displays  an  initial  alphabetic  choice  for  the  state  names: 


States 


ABCDEFGHIJ 


At  any  time,  the  experimenter  may  write  over  this  display 
to  replace  these  choices  by  his  own. 

THE  MESSAGE  CENTER 

If  we  remove  the  burden  of  tedious  work  only  to  replace 
it  with  a  large  set  of  system  rules  and  procedures  to  be 
learned,  the  experimenter  has  gained  very  little.  To  avoid 
this  pitfall,  FS5  has  a  MESSAGE  CENTER  which  prompts  the 
user  on  system  usage,  informs  him  of  conditions,  and  suggests 
actions  to  take  when  errors  occur.  In  other  words,  FS5 
supplies  copious  ru  i-time  diagnostics. 
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For  example,  when  the  experimenter  begins  to  write 
in  a  value  for  the  number  of  states,  FS5  prompts  him  with 


ENTER  NUMBER  OF  STATES 
SWEEP  TO  EXIT. 


If  he  beings  to  rewrite  the  external  state  names,  he  sees 


ENTER  NAMES  OF  STATES 
1=QUIESCENT  2=GENERAL 
LAST=FIRING 
SWEEP  PEN  TO  EXIT. 


Furthermore,  FS5  guards  against  such  illegal  procedures  as 
trying  to  enter  one  of  the  three  reserve  state  names — "#", 
"?" — in  this  case  by  refusing  to  accept  them. 

The  policy  on  a  user  error  is  to  announce  it,  correct 
it  and  leave  the  system  in  a  usable  condition  whenever 
possible,  or  else  inhibit  further  action  until  the  user 
makes  a  correction,  and  advise  him  how  to  do  so. 

ENTRY,  STORAGE  AND  RETRIEVAL  OF  FUNCTION  VALUES 

For  a  10-state  solution,  as  many  as  891  function  values 
might  be  needed.  As  a  complication,  a  large  number  of  pro¬ 
ductions  might  be  undefined  at  any  given  time.  FS5  pro¬ 
vides  several  ways  to  enter,  retrieve  and  alter  productions, 
and  takes  appropriate  action  when  an  undefined  production 
is  referenced. 


I 
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To  illustrate,  the  experimenter  may  enter  a  production 
by  writing 


DEFINE  FROZEN 


QQG  -  G 


If  he  later  wishes  to  recall  this  value,  he  writes 


DEFINE  FROZEN 


QQG  •>  ? 


and  FS5  replaces  the  "?"  by  the  value;  here  "G" ,  or  by 
if  the  production  is  undefined. 

Alternatively,  the  system  might  have  been  designed  to 
display  the  entire  state  table  upon  request.  However,  at 
any  one  moment  the  experimenter  is  usually  interested  in 
only  one  production.  Moreover,  many  table  entries  might 
never  be  of  interest,  because  no  simulation  needs  them. 

SIMPLE  SIMULATION  OF  A  FIRING  SQUAD 

After  defining  several  productions,  the  experimenter 
will  want  to  test  the  function  on  firing  squads  of  various 
lengths;  FS5  offers  several  modes  of  simulation  and  testing. 
For  a  simple  case,  suppose  that  a  simulation  is  desired  for 
length  4.  The  user  enters  the  "4"  with  the  stylus: 


LENGTH 


4 
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1 


FS5  responds  by  initializing  the  firing  squad: 


0 

1 

2 

3 

4 

5 

6 


Q  Q  Q  G 


F  F  F  F 


In  addition,  the  system  always  provides  two  productions: 


#QQ  ->  Q  and  QQQ  +  Q 


where  represents  the  end-marker  state.  These  are  the 

two  productions  required  by  the  problem  statement. 

Let  us  further  suppose  that  the  user  has  entered 

QG#  -*•  G,  QQG  -*  G,  QGQ  -*•  Q,  and  #GQ  G. 


He  starts  the  simulation  by  touching 


START  SQUAD 


Then  the  message  center  will  display 


FIRING  IN  PROGRESS. 
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Simulation  proceeds  from  time  1  down,  left  to  right  on 
successive  rows.  Because  the  Q  G  G  production  is  undefined, 
simulation  will  cease  at  time  2. 


0 

1 

2 

3 

4 

5 

6 


Q  Q  Q 
Q  Q  G 
Q  G  . 


•  • 


•  • 


F  F  F  F 


The  message  center  will  contain 


ERROR:  FUNC  NULL  &  SQAD  FREE, 

and  the  undefined  production  will  be  displayed, 


DEFINE  FROZEN 


QGG  . 


ready  for  the  experimenter  to  enter  a  value. 

A  simulation  may  be  temporarily  halted  at  any  time  to 
check  its  progress.  During  these  manual  stops,  FS5  con¬ 
tinues  to  advise  on  system  status;  and  messages  are  also 
provided  for  automatic  stops. 
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ENTER  CONSTRAINTS 

With  these  simple  services  at  his  disposal,  the  ex¬ 
perimenter  can  turn  his  attention  to  finding  good  solution 
approaches.  FS5  enables  him  to  enter  two-dimensional 
skeleton  plans  which  really  are  a  set  of  constraints  on 
the  function  behavior. 

The  state  at  time  zero  and  the  constraints  at  tho 
firing  time  are  fixed  by  the  problem  statement  and  provided 
by  the  system.  To  enter  other  constraints,  first  the  user 
touches 


DEFINE  CONSTRAINT 


after  which  FS5  replies  with  instructions.  Next,  the  user 
touches  two  points  to  define  a  line  segment  on  the  simu¬ 
lation  display,  and  then  a  name  in  the  STATE  display. 


In  other  words,  a  constraint  is  a  line  segment  of  states 
which  is  "drawn"  on  the  display. 
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Any  number  of  constraints  may  be  entered,  and  one  may 
be  drawn  over  another.  The  "."'s  in  the  display  are  in¬ 
tended  as  guides  in  determining  straignt  lines,  and  FS5 
automatically  provides  other  temporary  guides  and  markers  . 

If  an  error  is  made  or  a  change  desired,  the  last  constraint 
entered  may  be  erased: 


REMOVE  LAST 


The  ability  to  enter  constraints  becomes  a  powerful 
tool  when  used  in  conjunction  with  the  simulation  modes 
described  in  the  following  two  sections. 

SIMULATION  WITH  CONSTRAINTS 

If  the  experimenter  starts  a  simulation  for  length  4 
with  all  productions  undefined  except  for  #QQ  ■+  Q  and 
QQQ  Q>  and  with  the  three-position  constraint  of  the 
previous  example,  then  FS5  will  define  the  production 
QQG  ■*  G  from  the  constraint.  However,  the  simulation  will 
terminate  as  shown  below  because  neither  is  QG#  defined  nor 
is  the  simulation  constrained  at  the  position  where  QG#  is 
first  required. 
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0 

1 

2 

3 

4 

5 

6 


Q 

Q 

G 


Q 

Q 

G 


Q 

G 


Defined  by  constraint 
Undefined 


F 


F  F 


F 


The  ability  to  draw  large  numbers  of  complicated  constraints 
thus  relieves  the  experimenter  of  the  task  of  tailoring  many 
individual  productions  to  produce  the  same  behavior;  all  the 
necessary  definitions  are  made  by  the  system. 

The  system  also  detects  contradictions  between  con¬ 
straints  and  previously  defined  functions.  Such  an  error 
would  have  occurred  had  the  resultant  of  QQG  been  set  to  Q. 
These  contradictions  often  escape  notice  when  simulations 
are  performed  by  hand. 

As  an  alternative  to  drawing  constraints,  a  language  to 
describe  them  might  be  devised.  However,  it  is  hard  to 
imagine  a  language  as  easy  or  as  natural  to  use  as  the  FS5 
method. 

SIMULATION  WITH  BACKTRACKING 

As  mentioned  above,  exhaustive  search  for  a  function 
might  become  feasible  when  relatively  few  productions  re¬ 
main  undefined.  The  use  of  constraints  also  can  make  ex¬ 
haustive  search  feasible,  because  these  constraints  act  as 
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implicit  definitions.  To  take  advantage  of  constraints,  FS5 
was  equipped  with  a  widely  used  method  of  efficient  search 
called  the  "backtrack"  technique  [8-10] .  For  readers  not 
familiar  with  backtracking,  or  who  may  know  it  by  another 
name,  a  brief  review  is  in  order. 

Many  combinatorial  problems  can  be  stated  in  the  form, 

"Find  a  vector  (s.  ,  s_,  ...,  s  )  which  satisfies  p  ,"  where 

l  z  m  m 

s.,  s2,  •••,  are  to  be  chosen  from  a  finite  set  of  N 
distinct  objects,  and  pm  is  some  property.  The  "brute 
force"  approach  is  to  form  in  turn  each  of  the  Nm  possible 
vectors,  testing  whether  or  not  it  satisfies  pm>  A  back¬ 
track  algorithm  is  designed  to  yield  the  same  result  with 
far  fewer  trials. 

The  backtrack  method  consists  of  defining  properties 
p^  for  1  <  k  <  m  in  such  a  way  that  whenever  (s^,  s2,  ...,  sm) 
satisfies  pm,  then  (s^,  ...»  s^)  necessarily  satisfies  p^,. 

The  computer  is  programmed  to  consider  only  those  partial 
solutions  (s^,  ...,  s^)  which  satisfy  p^;  if  p^  is  not 
satisfied,  then  the  N™  ^  vectors  (s^,  ...,  s^,  s^+1,  . ..,  sm) 
are  not  examined  by  the  program.  When  all  choices  for  s^  are 
exhausted,  the  program  backtracks  to  make  a  new  choice  for 


s^-l.  If  the  properties  p^  can  be  chosen  in  an  efficient 
way,  comparatively  few  cases  are  considered. 


In  the  firing  squad  problem,  the  vector  (s^,  s2,  .  ..,  sm) 
consists  of  production  definitions.  The  backtrack  method 


applied  in  FS5  serially  defines  the  productions  as  they  are 
needed  in  the  simulation  of  a  firing  squad  of  fixed  length  M. 
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The  method  begins  with  all  productions  undefined  except 
the  two  required  by  the  problem  statement.  After  initializing 
the  firing  squad  for  length  M,  the  program  begins  to  find  the 
new  state  of  each  position  in  the  simulation  according  to  the 
productions  which  are  already  defined.  If  a  production  is 
encountered  which  is  not  already  defined,  and  this  occurs  at 
an  unconstrained  position,  then  the  resultant  is  set  to 
either  the  firing  state  or  another  state,  depending  on 
whether  or  not  this  occurs  at  firing  time.  If  the  position 
is  constrained,  the  resultant  is  set  to  the  constraint  value. 

The  process  of  serial  definition  continues  until  an 
error  occurs.  An  error  is  defined  to  be  either  a  soldier 
going  into  the  firing  state  before  firing  time,  a  soldier 
not  firing  at  firing  time,  or  a  conflict  between  a  constraint 
and  a  production  already  defined.  When  an  error  occurs,  FS5 
backtracks  to  find  the  most  recently  defined  production 
whose  resultant  is  not  the  firing  state,  which  is  first  used 
where  there  is  no  constraint,  and  for  which  all  the  choices 
of  a  resultant  have  not  been  exhausted.  All  productions 
defined  after  this  are  now  undefined,  and  this  production 
is  set  equal  to  a  value  which  has  not  yet  been  tried  for 
it.  The  program  then  returns  to  the  position  in  the  firing 
squad  simulation  where  this  production  was  first  defined, 
and  simulation  continues  from  there. 

The  above  process  of  finding  the  new  state  of  a  soldier 
and  defining  production  as  needed  is  continued  until  either 
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a  solution  is  found  for  length  M  or  else  no  productions 
remain  which  are  alterable.  In  the  latter  case,  we  have 
tried  all  possibilities  which  could  lead  to  a  solution  for 
the  given  length  with  the  given  constraints  and  a  given 
number  of  states.  Thus  there  is  no  solution  in  this  form. 

The  experimenter  can  request  FS5  to  simulate  in  "AUTO" 
mode,  in  which  case  backtracking  will  be  applied  to  any  un¬ 
defined  productions  which  are  needed.  Backtrack  mode  may 
be  used  with  or  without  either  constraints  or  explicit 
production  definitions  having  been  entered.  Simulation 
will  only  cease  if  either  a  successful  function  is  found 
or  all  possibilities  are  exhausted. 

FROZEN  AND  FREE  PRODUCTIONS 

The  experimenter  can  freeze  the  value  of  a  production 
if  he  wishes  to  prevent  its  alteration  without  his  explicit 
consent;  the  key  productions  are  of  this  nature.  Frozen 
productions  are  not  altered  by  any  simulation  mode.  Hence, 
a  frozen  production  is  another  form  of  constraint  and,  if 
used,  may  further  reduce  backtracking  effort.  Other  pro¬ 
ductions  are  termed  free  because  the  backtracking  mechanism 
is  free  to  alter  them. 

SNAP  VIEW  AND  BRIGHT  POSITIONS 

While  in  backtracking  mode,  it  is  useful  and  necessary 
to  view  the  progress  of  the  simulation.  Sometimes  the  ex¬ 
perimenter  can  notice  an  area  where  much  backtracking  occurs, 
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and  enter  explicit  frozen  production  or  additional  con¬ 
straints  to  eliminate  such  bottlenecks.  Furthermore,  if 
the  constraints  are  neither  numerous  nor  strong,  the  number 
of  search  possibilities  could  still  be  astronomical.  In 
this  case,  if  the  experimenter  periodically  views  the 
progress  of  the  simulation,  he  can  decide  when  it  should 
be  aborted. 

With  the  "SNAP  VIEW"  option  "ON,"  redisplay  of  the 
simulation  occurs  after  each  row  is  completed  and  also 
whenever  the  system  must  backtrack.  Otherwise  (and  in  all 
cases  of  "STOP"  mode) ,  redisplay  occurs  only  when  simula¬ 
tion  terminates.  Since  a  position  in  a  simulation  at  which 
a  production  is  first  used  is  of  special  interest,  all  such 
positions  may  be  brightened  by  pushing  a  button: 


BRIGHT 


Both  features  are  optional  because  frequent  redisplay 
significantly  increases  running  time. 

HISTORY  SCROLL,  FREEZING  AND  DELETION 

Although  the  experimenter  may  never  be  interested  in 
seeing  the  entire  production  table  at  one  time,  he  may  have 
occasion  to  view  significant  portions  of  it.  A  scroll  dis¬ 
play  gives  him  the  list  of  productions  used  in  the  current 
terminated  simulation,  in  order  of  original  usage,  and  in¬ 
dicates  which  are  frozen. 
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If  production  definitions  were  generated  by  con¬ 
straints  or  backtracking,  he  might  want  to  freeze  some  or 
discard  others.  Either  can  be  done  by  pushing  the  appro¬ 
priate  button 


FREEZE  VALUE 


DELETE  VALUE 


and  touching  productions  on  the  scroll . 

IMAGE  SOLUTIONS 

Experience  with  the  problem,  and  general  considera¬ 
tion  of  the  form  that  any  solution  must  take,  led  to  giving 
FS5  another  heuristic  tool,  which  requires  explanation 
because  its  motivation  is  less  obvious  than  that  of  other 
program  features. 

In  any  solution,  signals  must  travel  the  entire  length 
of  a  squad  in  both  directions  because  the  general,  before 
he  can  fire,  must  know  that  the  order  to  fire  has  reached 
the  last  soldier  on  the  opposite  end  of  the  squad.  If  the 
signal  sent  by  the  general  is  1,  and  the  signal  returned 
by  the  last  soldier  is  2,  then  we  may  think  of  signal  2  as 
being  the  image  produced  by  the  reflection  of  signal  1  from 
the  end  of  the  squad.  In  other  words,  the  general  bounces 
signal  1  off  the  end  of  the  squad;  the  image--echo--returns 
to  him  as  signal  2. 
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Experience  with  various  solution  methods  has  demon¬ 
strated  many  other  instances  in  which  the  image  analogy  is 
helpful.  For  example,  suDpose  that  we  are  applying  the 
technique  of  successive  subdivision,  and  have  contrived  a 
partial  skeleton  plan: 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 


The  general  emits  signal  1,  and  it  travels  to  the  left  at 
the  maximum  possible  rate  of  one  man  per  unit  of  time. 
This  signal  arrives  at  the  end  of  the  squad  and  produces 
an  image,  signal  2,  which  travels  at  the  same  rate  in  the 
opposite  direction. 
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The  general  also  emits  signal  3,  and  it  travels  at  one- 
third  the  rate  of  signal  1.  Thus,  signals  2  and  3  meet  at 
the  midpoint  of  the  squad  and  produce  the  first  division 
point.  This  central  soldier  is  then  promoted  to  general, 
and  the  process  can  be  repeated  for  each  of  the  two  halves. 

To  repeat  the  process,  the  central  general  sends  signal 
1  to  the  left  as  before,  but  now  a  signal  4  is  also  sent  to 
the  right.  Signal  4  is  intended  to  behave  in  the  same 
manner  as  1,  except  that  4  travels  in  the  opposite  direc¬ 
tion.  Signal  4  is,  therefore,  an  image  of  signal  .1,  created 
by  reflection  about  the  center  of  the  squad. 

Images  imply  that  certain  symmetries  will  probably 
exist  between  sets  of  productions  and  between  pairs  of  states. 
Therefore,  an  additional  heuristic  for  the  problem  is  to  look 
for  solutions  having  the  property  that  for  every  production 
LMR  ■*  S  there  exists  a  production. 

Image  (R)  Image  (M)  Image  (L)  -*•  Image  (S) 

where  the  Image  function  maps  the  set  of  states  onto  itself 
such  that  Image  (Image  (S))  =  S  for  all  states  S. 

In  FS5,  if  the  image-solution  mode  is  selected  and  the 
user  defines  a  proper  image  mapping,  then  whenever  a  pro¬ 
duction  is  defined,  the  image  production  is  also  defined. 

The  image  method  may  be  used  separately  or  in  combination 
with  constraints  and  backtracking.  Obviously,  the  image 
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method  also  improves  the  feasibility  of  exhaustive  search 
because  the  number  of  free  productions  is  again  reduced. 

MISCELLANEOUS 

Other  controls  allow  for  reinitializations,  for  simu¬ 
lation  testing  over  any  range  of  lengths  up  to  500  men, 
and  for  hard  copy  of  displays  and  tables. 
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V.  IMPLEMENTATION  EXPERIENCE  AND  PREREQUISITES 

Any  system  like  FS5  endeavors  to  provide  the  researcher 
with  tools  and  response  time  that  encourage  and  allow  him 
to  apply  methods  of  solution  which  might  otherwise  be  im¬ 
practical.  On  the  other  hand,  if  the  labor  of  writing  the 
software  is  greater  than  the  hand  calculation  it  eliminates, 
a  researcher  finds  small  encouragement.  In  general,  if  the 
cost  o f  building  an  interactive  system  exceeds  the  importance 
of  the  problem  area,  the  system  will  not  be  built.  Our  feel¬ 
ing  is  that  the  cost  of  FS5  is  reasonable,  and  that  costs 
relative  to  more  important  problems  will  be  significantly 
lower . 

The  required  hardware  includes  a  digital  computer,  a 
CRT  display  with  appropriate  graphic  input  device,  and 
associated  interface  equipment.  The  choice  of  input  device 
is  crucial  to  human  reaction.  A  light  pen  is  at  best  a 
clumsy  pointing  instrument,  and  a  typewriter  keyboard  with 
display  cursor  is  an  unnatural  tool.  Had  these  been  the 
only  devices  available,  many  FS5  features  would  have  been 
neither  conceived  nor  implemented.  An  appliance  used  in 
the  manner  of  a  pencil,  such  as  the  RAND  Tablet,  is  central 
to  the  efficacy  of  interactive  problem-solving  systems. 

FS5  required  three  software  types,  exclusive  of  pro¬ 
gramming  language  and  operating  system:  a  graphic  software 
system  (IGS);  routines  to  service  displays  and  controls; 
and  routines  providing  non-graph ical  aids.  IGS  allows  the 


-31- 


user  to  think  globally  about  displays  for  his  problem, 
rather  than  about  intricate  hardware  and  bit  patterns. 
Routines  to  generate  and  manage  displays  consist  primarily 
of  calls  to  IGS.  Non-graphical  routines,  such  as  table 
maintenance  and  backtracking,  were  no  different  than  they 
would  have  been  if  all  output  was  printed. 

Thus,  the  major  efforts  in  writing  FS5  were  to  design 
displays  and  to  interface  with  the  existing  graphic  soft¬ 
ware.  With  such  high-level  languages  as  PL/I  or  FORTRAN, 
and  a  good  package  such  as  IGS,  this  is  not  a  very  dif¬ 
ficult  task. 
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VI.  CONCLUSION 

An  on-line,  graphical,  man/machine  interactive  computer 
system  can  provide  greatly  increased  research  power  over  a 
system  lacking  these  attributes.  This  is  true  even  when  a 
problem  is  not  inherently  graphical.  Anyone  who  is  plan¬ 
ning  a  computer  system  to  investigate  a  difficult  problem 
area  should  consider  extending  the  design  to  make  it  graphical 
and  interactive.  Since  most  medium  and  large  computer  fa¬ 
cilities  already  have  the  necessary  hardware  and  basic  soft¬ 
ware,  and  since  construction  of  routines  to  generate  and  to 
manage  displays  is  quite  simple,  the  added  cost  should  be 
very  small  compared  to  the  extra  utility  gained. 
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